Add Linking.openNotificationSettings() - #58487

Summary:

Linking.openSettings() opens Settings → Your App. Both platforms have had an official, App-Review-safe way to land one level deeper, on the app's notification settings, for years, but React Native does not expose either:

• iOS 15.4+: UIApplication.openNotificationSettingsURLString
• Android 8.0+ (API 26): Settings.ACTION_APP_NOTIFICATION_SETTINGS with Settings.EXTRA_APP_PACKAGE

Today apps either reach for undocumented prefs:root= / App-Prefs: URLs on iOS (a known App Store rejection risk), or hand-roll Linking.sendIntent on Android (the existing RNTester Linking example does exactly this). Sending users to the right screen after a denied notification permission is a very common flow, so this belongs in core next to openSettings(), which was added the same way in #23965.

This PR adds Linking.openNotificationSettings(): Promise<void>:

• iOS: uses UIApplicationOpenNotificationSettingsURLString on iOS 15.4+, guarded with @available since the minimum deployment target is 15.1. On 15.1–15.3 it falls back to UIApplicationOpenSettingsURLString. The openURL + resolve/reject logic is shared with openSettings via a small private helper.
• Android: launches ACTION_APP_NOTIFICATION_SETTINGS with EXTRA_APP_PACKAGE on API 26+, and falls back to ACTION_APPLICATION_DETAILS_SETTINGS on API 24–25. Intent flags match openSettings. The shared intent-building / activity-start code is factored into private helpers reused by openSettings.
• JS: new method on Linking, TurboModule spec entries for NativeLinkingManager and NativeIntentAndroid, legacy .d.ts types, regenerated ReactNativeApi.d.ts snapshot, ReactAndroid.api entry, jest-preset mock, RNTester example.
• Tests: new Linking-test.js covering platform dispatch for openSettings / openNotificationSettings; new Robolectric tests in IntentModuleTest covering the API 26+ intent, the API 25 fallback (@Config(sdk = [25])), and rejection when there is no current activity.

Fallback rather than rejection on old OS versions was chosen deliberately: callers want "take the user as close as possible to the notification toggle", and the general app settings page is that on those OS versions. Behavior is documented in the JSDoc.

Changelog:

[GENERAL] [ADDED] - Add Linking.openNotificationSettings() to open the app's notification settings on iOS (15.4+) and Android (API 26+), falling back to the app settings page on older OS versions

Test Plan:

All run locally on macOS (Xcode 26.3, Zulu JDK 17, Node 22.23) against main:

yarn flow check                                         # No errors!
yarn eslint --max-warnings 0 <changed js/ts files>      # clean
yarn prettier --list-different <changed js/ts files>    # clean
yarn build-types                                        # regenerates ReactNativeApi.d.ts (only Linking hash + new method)
yarn jest packages/react-native/Libraries/Linking packages/jest-preset
#   Tests: 5 passed (4 new Linking-test.js + jest-preset setup-test)
./gradlew :packages:react-native:ReactAndroid:testDebugUnitTest --tests "*IntentModuleTest*" \
          :packages:react-native:ReactAndroid:ktfmtCheck
#   BUILD SUCCESSFUL - IntentModuleTest: 5 tests, 0 failures (4 new)

Android (RNTester, Pixel 9 Pro API 35 emulator): built and installed via :packages:rn-tester:android:app:installDebug. Linking → "Open notification settings" → Settings opens directly on Settings$AppNotificationSettingsActivity for RNTester.

iOS (RNTester, iPhone 17 Pro, iOS 26.3 simulator): built via xcodebuild -workspace RNTesterPods.xcworkspace -scheme RNTester, no warnings from RCTLinkingManager.mm. Calling Linking.openNotificationSettings() brings the Settings app to the foreground and the promise resolves. Note: on the iOS Simulator both openSettings() and openNotificationSettings() land on the Settings root screen (the Simulator's Settings app does not expose third-party app pages), so the exact landing page could only be confirmed on Android; on a device iOS 15.4+ resolves UIApplicationOpenNotificationSettingsURLString to Settings → App → Notifications per Apple's documentation.

Not tested: the iOS 15.1–15.3 and Android API 24–25 fallback paths on a device/emulator (no such runtimes available locally); the Android fallback is covered by the @Config(sdk = [25]) Robolectric test.